Seven Keys to Project Success for Large Software Systems

Introduction

After decades of concern about the failure rate of software projects, veteran project managers can point to a steady increase in the quality of development projects.  Great progress has been made in software development methodologies and the ability to assess the quality of development organization processes. Most large organizations have invested heavily in implementing process standards developed by ISO and IEEE, and they continuously improve performance by measuring themselves against the corresponding ISO or CMMI© process assessment criteria. 

Despite the negative media hype generated by large project failures like the ObamaCare fiasco, life is getting better.  The improvements are certainly a cause for celebration, but we are far from total victory.  Recent surveys show that outright project failures have fallen to a range of 20 to 30 percent, but that large projects fail at a significantly higher rate than small ones.  Unfortunately, half of projects that don’t fail still experience serious issues with cost, schedule, and functionality.

Success Factors Overview

Software systems require a great deal of cooperation and coordination.  Large, complex organizations create serious challenges for an IT department.  Dealing with multiple geographic locations and business divisions, navigating complex organization structures and sorting through inter-organization politics can create challenges that make the technical issues seem almost easy. 

Based on several decades of managing software systems projects in a very large corporation, these are the seven most critical factors for success:

1. Strong Project Ownership
2. Trusted Technical Leader with Deep Business Knowledge
3. Clear and Open Decision Making
4. Proper Business Alignment
5. Classifying Research as Research
6. Realistic Scope and Project Plan
7. Proper Risk Management

Each factor is described in more detail along with a set of probing questions that can be used during project reviews to drive out issues. 

Success Factor Details

Strong Project Ownership | Trusted Technical Leader with Deep Business Knowledge | Clear and Open Decision Making | Proper Business Alignment | Classifying Research as Research | Realistic Scope and Project Plan | Proper Risk Management

Factor 1: Strong Project Ownership

Launching a project in a large business or organization without a strong business owner is like leading an army into battle without a general.  The owner must be an enthusiastic but realistic project advocate and must be able to communicate its importance up, down, and across the organization chart.  There must be only one project owner and they must be at a management position and level appropriate to the scope, cost and importance of the project.  Perhaps more importantly, they must exercise a level of control commensurate with the personal consequences of project failure.  Lack of involvement by Kathleen Sebelius (former Secretary of Health and Human Services) in ObamaCare was a major contributor to project failure.  But, as she replied to a congressional hearing when asked to call out one of her subordinates as the chief culprit, "Excuse me, congresswoman.  Hold me accountable for the debacle. I’m responsible."  (New York Daily News, October 31, 2013)

Questions:

• Is the project owner in the appropriate business function and at a level commensurate with the scope and cost of the project?
• Does the project owner have a thorough and realistic understanding of the project and are they committed to project success?
• If the project owner has delegated any project responsibilities, is there sufficient communication between the owner and the delegate to preclude confusion, mistrust, and disruption?
• Does the project owner have a good plan to provide sufficient business-side resources (people, money, equipment)?
• Does the project owner have a trustworthy communication/coordination network with managers in other organizations impacted by the project, especially with those organizations that will actually use the new system?
• If the project owner changes jobs, are they still in an appropriate position to continue their duties.  If not, is their replacement qualified and willing to carry out the role?

Factor 2: Trusted Technical Leader with Deep Business Knowledge

Most projects have a technical leader who deeply understands the technology.   Successful projects have a technical leader who also understands the major components of the business process.  Experience actually working in the supported business process is highly recommended.

Questions:

• Does the technical leader know enough about both IT technology and the business process to provide accurate guidance on trade-offs between schedule, functionality, and cost?
• Is the technical leader trusted by both IT and the supported business organization?
• Is the technical leader able to judge and explain the impact of scope/content changes on fundamental project business goals?
• Does the technical leader have the business knowledge and respect to successfully negotiate when business process experts disagree with each other?

Factor 3:  Clear and Open Decision Making

Successful projects have frequent, open, and honest communication in determining and communicating direction, and the people responsible for the success of the project are continuously involved. 

Questions:

• Are all key stakeholders involved in the decision making process?
• Are decisions sometimes made “after the meeting” by only one or two people?
• Are important decisions always documented and communicated?
• Are project reviews held on a regular basis?
• Are reviews being attended by substitutes/delegates rather than the people who really care about project success?
• Are actions arising from project reviews clearly documented, assigned, accepted, and tracked?
• Are there negative consequences for reporting the truth?
• Are project communications clear, simple, and tailored to the audience – or are they too technical and sometimes ambiguous?

Factor 4: Proper Business Alignment

Successful modern organizations innovate and adapt quickly, and execute multiple improvement initiatives in parallel.  It is critical that large (and long) IT projects maintain alignment with the ever-changing organization.  Does it make sense to continue with a warehouse parts tracking project if the company direction is to move to a just-in-time inventory approach?  Should work continue on automating an existing business process if a recently acquired subsidiary has a superior and already automated process that will likely become the company standard? 

Questions:

• Are project goals documented and understood in business process terms?
• Are project goals evaluated and realigned as business goals shift over time?
• Does the project have potential conflicts with other projects or business initiatives that may cause future disruption or cancellation?
• Are the project goals and scope clearly documented and easily understood by people outside the project boundary?
• Is the project in sync with the organization-wide computing direction and architecture?

Factor 5: Classifying Research as Research

There is a big difference between the “R” and the “D” of “R&D.”  A sure path to failure is to treat a research project as a development project.  Vendors or internal IT “experts” can easily mislead the business about the maturity level of the technology they promote.  All too often the level of risk created is not recognized or accounted for in the project plan.  A research project can be a great idea, but not if executive expectations are based on typical results for a development project. 

It’s not just the IT component of the project that can create this issue.  Throwing new technology at a poorly understood business process can’t even be called research, let alone development.  It can best be labeled as reckless experimentation.  The outcome will be wasted money and project cancellation – followed by painful punishment for IT leaders.  The only benefit will be a slightly improved understanding of the current business process.  Look for the phrase, “constantly changing requirements”, one of the most common symptoms of a poorly understood business process.  For example, the Los Angeles School System just finished spending $130 million and more than a decade trying to centralize and automate their student records process.  Years of frustration led the district to sue the software subcontractor.  Unfortunately, the courts agreed with the contractor’s assertion that internal dysfunction in the district led to “constantly changing requirements” and faulted the district for much of the problem. (LA Times, 10/14/2014).  The district fired the contractor and created an internally coded solution.  As might be expected, this version is also plagued with major issues.  For the sake of California taxpayers let’s hope this $130 million research project is complete and that the district now understands enough about its requirements to proceed with an actual development project.

Questions:  

• Is this a research project disguised as a development project?
• Does the project involve unproven computing technology or yet-to-be-defined business processes?
• If this is a research project, are the project plan and the expected outcomes appropriate?
• Is the technology recommended because it fits a known business need, or is it an expensive solution desperately searching for a problem to solve?
• Are the business requirements and the technology mature enough for a waterfall project plan or is a spiral method like Agile more appropriate?
• Are requirements constantly changing?

Factor 6: Realistic Scope and Project Plan

This may the most difficult area for software engineers and IT project managers to maintain objectivity.  Exciting new projects are difficult for them to resist, especially if they have been involved in developing the concepts and promoting the benefits.  It can be tempting to ignore potential risk and complexity – but it can be very dangerous.  

Questions:

• Is the delivery date based on a predefined organization need date or is it based on a realistic understanding of the actual tasks needed to be accomplished?
• If the project is very large, is it designed to be implemented in several meaningful phases?
• Are labor estimates based on the skill level of the estimators or on the skill level of the people who will actually do the work?
• Has required integration with existing business processes and systems been completely accounted for, and are there experts available to work their ends of the integration tasks?
• Does the project plan and business case include all the computing elements required to implement? – servers, networks, workstations, scanners, etc.
• Does the project include impacts to the using organizations, e.g. training costs and business disruption during training and implementation?
• Is there a realistic plan for performance and scalability testing, usability testing, conversion of data from existing systems, production support, security, and ongoing maintenance?
• Are there hidden or poorly understood interfacing systems or business processes that will fail when the new system is implemented?

Factor 7: Proper Risk Management

Although risk management has traditionally been a strong component of project planning in other industries, recognition of its importance has been slow to materialize in the software development discipline.  Current standard methodologies now have well defined elements to identify, control, and track risk.  Projects that regard risk management as a lower priority are bound to fail.  Large and complex software projects may have important risks that go unrecognized or are improperly labeled as "assumptions." 

Questions:

• Are risks improperly identified as assumptions?  For example, an “assumption” that no key technical personnel will leave the project actually represents an important risk that needs to be managed.
• Are there risks that have not been documented, especially with subcontractors or other outside organizations supporting the project?
• Is there a plan for each identified risk?
• Are risks a standard agenda item in project reviews?
• Is there contingency funding for risk impacts?

Conclusion

I recommend that project managers hold a special project review quarterly to address these success factors.  Most questions will be appropriate regardless of the project stage.  Please have the courage to recommend major changes or outright cancellation of a project if it continuously fails this review.

Please send questions or comments to Ed Holmes, edward.holmes@hotmail.com